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FOREWORD 


The Software Engineering Laboratory (SEL) is an organization 
sponsored by the National Aeronautics and Space 
Administration/Goddard Space Flight Center (NASA/GSFC) and 
created for the purpose of investigating the effectiveness 
of software engineering technologies when applied to the 
development of applications software. The SEL was created 
in 1977 and has three primary organizational members: 

NASA/GSFC (Systems Development and Analysis Branch) 

The University of Maryland (Computer Sciences Department) 
Computer Sciences Corporation (Flight Systems Operation) 

The goals of the SEL are (1) to understand the software 
development process in the GSFC environment; (2) to measure 
the effect of various methodologies, tools, and models on 
this process; and (3) to identify and then to apply success- 
ful development practices. The activities, findings, and 
recommendations of the SEL are recorded in the Software 
Engineering Laboratory Series, a continuing series of re- 
ports that includes this document. A version of this docu- 
ment was also issued as Computer Sciences Corporation 
document CSC/TM-82/6214. 

The contributors to this document include 

Michael Rohleder (Computer Sciences Corporation) 

Frank McGarry (Goddard Space Flight Center) 

Jerry Page (Computer Sciences Corporation) 

David Card (Computer Sciences Corporation) 

Single copies of this document can be obtained by writing to 

Frank E. McGarry 
Code 582.1 
NASA/GSFC 

Greenbelt, Md. 20771 
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ABSTRACT 


This document is a glossary of terms used in the Software 
Engineering Laboratory (SEL) . The terms are defined within 
the context of the software development environment for 
flight dynamics at Goddard Space Flight Center. The intent 
of this document is to provide a concise reference for 
clarifying and understanding the language employed in SEL 
documents and data collection forms. 
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SECTION 1 - INTRODUCTION 


The glossary of Software Engineering Laboratory (SEL) terms 
presents a comprehensive collection of frequently used soft- 
ware engineering terms and expressions. Its objectives are 
to 

• Provide a reference for clarifying the language of 
SEL documents and data collection forms 

• Establish standard definitions for use by SEL per- 
sonnel 

• Explain basic software engineering concepts 


The defintions provided for the terms in this document are 
the local (SEL) usages and have been compiled from many 
sources: SEL personnel, software engineering literature, 

and publications of computer software terminology. 


I 
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SECTION 2 - SOFTWARE ENGINEERING TERMS 


acceptance testing 


adaptability 


adjusted lines of 
code 


algorithm 


analyzer 


archive 


argument 


array 


assemble 


Independent testing to verify accept- 
ance criteria for program certifica- 
tion. The software pass/fail criteria 
are predetermined. Failure to meet 
all criteria causes rejection of the 
software product. 

A measure of the ease with which a 
program can be altered to fit differ- 
ing user and system constraints. 

All new code plus 20 percent of the re- 
used code, minus 50 percent estimated 
as the amount of comment lines, minus 
10 percent estimated as the amount of 
nonexecutable statements. This meas- 
ure is an estimate of the number of 
executable lines of code developed. 

A prescribed set of well-defined rules 
or processes for the solution of a 
problem. 

Computer software used as a tool that 
is applied to a program to provide 
analytical information; it breaks the 
program into identifiable segments and 
reports statistical information. This 
information can include execution 
frequency statistics, program path 
analysis, and/or source code syntax 
analysis. 

Process involving the transfer of data 
or information from one source or vol- 
ume to another to provide a backup or 
alternate copy of the information for 
future use. 

Variable or expression passed to an 
operation or function as input or out- 
put. 

An ordered group or collection of 
variables, terms, or expressions. An 
array is usually dimensioned (or in- 
dexed) . 

As done by an assembler. 
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assignment 

statement 


attribute list 


baseline diagram 


batch 


block diagram 


bug 


build 


An expression or instruction used to 
assign values to specified variables 
or symbols. Includes all statements 
that change the value of a variable as 
their main purpose (for example, read 
statements) . However, the assignment 
of the iteration counter in a DO 
Statement is not included. 

A compiler-generated list of the iden- 
tifiers used by a program. It de- 
scribes the characteristics of those 
identifiers and shows the source 
statements where they are defined (or 
used) and the (relative) storage loca- 
tions of variables. 

A hierarchical graph of a software 
design listing all components in the 
system, A connection from a higher 
component to a lower one indicates 
that the higher component calls the 
lower one. 

Mode of operation of a computer in 
which the entire job is read into the 
machine before processing begins and 
in which there is no provision for 
interaction with the submitter during 
execution of the job. 

A diagram of a system or computer in 
which the principal parts are repre- 
sented by geometrical figures that 
show both the basic functions and the 
functional relationships among the 
parts. 

An error in the design or implementa- 
tion of a program. One or more soft- 
ware bugs exist in a system if a 
software change is required to meet 
specified or implied system perform- 
ance requirements. 

A functional subset of a more complex 
software development product. The 
"builds" approach to software develop- 
ment consists of developing a series 
of increasingly complete functional 
systems. 
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business and 

financial 

applications 

calibration error 

certification test 

change 

clerical error 
code 

code and unit test . 

code reading 
coding 

command/control 

compile 


Software or software system components 
related to some accounting, finance, 
or business data maintenance and re- 
porting. 

An error in the gauge or tolerance of 
specifications. 

A formal demonstration to the customer 
showing that requirements have been 
met. 

A modification to requirements, de- 
sign, code, or documentation made to 
correct an error, improve system per- 
formance, add capability, improve ap- 
pearance, or implement a requirements 
change. 

An error made in the process of copy- 
ing an item from one format to another 
or from one medium to another, which 
involves no interpretation or semantic 
translation. 

A symbolic representation of a func- 
tion composed of computer program 
statements. 

Life cycle phase in which code is 
developed or modified to meet design 
specifications. Each module (or unit) 
is integrated into the system and 
tested to ensure that the newly added 
capabilities function correctly. 

Inspection of the source code by per- 
sons other than the creator of the 
code in an attempt to detect errors. 

The generation of a symbolic represen- 
tation of a function that can be exe- 
cuted by a computer. 

A class of software including programs 
used either to generate vehicle com- 
mands or to transmit these commands 
from the control center. 

To translate a computer program ex- 
pressed in a problem-oriented human 
readable language into a computer- 
oriented, machine executable language. 
This includes the function of an as- 
sembler. However, some compilers pro- 
duce assembler rather than machine 
code. 
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complexity 


component 


computer 

architecture 


confidence level 


configuration 

control 


configuration 

management 


control statement 
control structure 

convention 

correction 


A measure of the difficulty of imple- 
menting or understanding a component, 
independent of the implementor's ex- 
perience; for example, the degree of 
interactions and number of dependen- 
cies among elements of a computer pro- 
gram. 

A named piece of a system; for 
example, a separately compilable func- 
tion, a functional subsystem, or a 
shared section of data such as a 
COMMON block. 

The relationships between the parts of 
a computer system; the structural and 
functional definition of a computer as 
viewed in terms of its machine in- 
struction set and input/output cap- 
abilities. 

The probability that a given statement 
is correct; 100 percent means that the 
statement is invariably true. 

A methodology for controlling the con- 
tents of a software system; a way of 
monitoring the status of system com- 
ponents, preserving the integrity of 
released and developing versions of a 
software system, and controlling the 
effects of changes throughout the sys- 
tem. 

All activities related to controlling 
the contents of a software system: 
monitoring the status of system com- 
ponents, preserving the integrity of 
released and developing versions of a 
system, and controlling the effects of 
changes throughout the system. 

A statement that potentially alters 
the sequence of executed instructions 
(for example, GOTO, IF, RETURN, DO) . 

A recurrent pattern of control state- 
ments (for example, sequence, itera- 
tion, selection) . 

An agreed-upon method, notation, or 
form of presentation. 

A change made to correct an error. 
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cosmetic change 


cost estimation 


cost effective 


costing technique 


criticality 


data 


A change in the source program made to 
improve clarity that has little effect 
on the performance of the program; for 
example, comment correction, movement 
of code that does not alter the imple- 
mented algorithm, or changing the name 
of a local variable. 

Prediction of the amount of labor 
necessary to complete a task, the 
amount and potential costs of computer 
time required, etc., before and during 
a project's life cycle. 

A term used to describe a process 

deemed to perform a task correctly and 
completely with a minimum waste of 
resources. 

A method for determining the cost of 
developing a system or any particular 
part of a system. 

A measure of the degree of dependence 
of the whole on a part of a system. 

A series or collection of measurements. 


data base 

data collection 

data definition 
language 

data dictionary 

data processing 

data set 
data structure 
data type 


A set of data files that are logically 
related. An organized system of stor- 
ing data. 

The methods (that is, forms, proce- 
dures, personnel) for collecting meas- 
urements. 

A special-purpose language used to de- 
fine data items in a data base and to 
create a data dictionary. 

A file that describes the format of 
fields, values, and records in a data 
base. 

A class of software whose primary 
function is the movement, formatting, 
and storage of data. 

A physical data storage location, 
usually magnetic tape or disk. 

The logical relationship among the 
units of data in a data base. 

A set of attributes used to define a 
data item. 
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data validation 


data base management 
system (DBMS) 


debugging 


The process of verifying the complete- 
ness and accuracy of data. 

A software system for managing a data 
base, usually consisting of a data 
definition language and a data access 
language. 

The process of locating and correcting 
software errors. 


design 


design language 


design phase 


A description of what a system must 
do, its components, the interfaces 
among those components, and the sys- 
tem’s interfaces with the external 
environment. 

A symbolic representation of a design, 
usually input to an analyzer program 
to detect errors and ambiguities. 

The life cycle phase in which the 
structure of a system is planned and 
recorded. 


design phase, 
preliminary 


design phase, 
detailed 


The specification of major functional 
subsystems, input/output interfaces, 
processing modes, and implementation 
strategy. The software system archi- 
tecture is defined, based on the re- 
quirements given in the functional 
specification and requirements 
document, and translated into software 
requirements in the requirements anal- 
ysis summary report. 

The extension of the system architec- 
ture defined in the preliminary design 
phase to the subroutine level. The 
preliminary design is elaborated by 
successive refinement techniques to 
produce a ”code-to" specification for 
the system. 


design reading Inspection of the design by persons 

other than the creator of the design. 

design review A formal meeting between customer and 

developer to determine that a proposed 
software configuration will satisfy 
performance specifications. 

design specification A document containing the approved 

design requirements for a program. 
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design verification 


development phase 


developed lines of 
code 

discrepancy 


documentation 


driver 


dynamic allocation 


effectiveness 


efficiency 


effort 


element 
end date 


The formal examination or inspection 
of a software specification for the 
purpose of finding design errors and 
ambiguities. 

The development and recording of code 
and inline comments based on the de- 
sign, Includes the modification of 
code caused by design changes or er- 
rors found in testing. (See code and 
unit test.) 

The total number of new lines of source 
code plus 20 percent of reused code. 

The difference between the intention 
of a specification and its actual 
implementation. 

Written material, other than source 
code statements, that describes a sys- 
tem or any of its components. 

A software component developed specif- 
ically to call other components; used 
in an informal testing technique dur- 
ing the implementation phase. 

The allocation of memory required by 
an operating program during its execu- 
tion phase rather than prior to execu- 
tion. 

The degree to which a system can suc- 
cessfully meet an operational demand 
within a given time when operated 
under specified conditions. 

The ratio of useful work performed to 
the total energy expended. Code is 
efficient to the extent that it ful- 
fills its purpose without wasting re- 
sources. 

The amount of resources, including 
manpower and computer time, necessary 
to complete a particular project; 
total energy expended. 

A basic segment of a named piece of a 
system (component) . 

The date that a phase is scheduled to 
be completed. 
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embedded system 


environment 


error 


error analysis 


error recovery 


A dedicated computer system that is 
physically incorporated into a larger 
system whose primary function is not 
data processing, for example, an elec- 
tromechanical system. 

The combination of all external or 
extrinsic conditions that affect the 
operation of an entity. The combina- 
tion of hardware and software used to 
maintain and execute the software, 
including the computer on which the 
software executes, the operating sys- 
tem for that computer, support libra- 
ries, text editors, compiler, etc. 

An internal condition that prevents a 
software system from successfully per- 
forming its intended function. (See 
calibration error, clerical error.) 

The examination of errors with the 
purpose of tracing them to their 
sources and determining their effects. 

The ability of a system to resume 
processing rather than abort after an 
error.' 


estimation parameter Any estimator or contributing factor 

to the process of estimation. 

executable statement Statement that changes the value of 

data or the state of a program. 

execution Performance by a computer of the in- 

structions in a program. 


execution time 
external reference 

failure rate 

failure, software 


The actual processor time used in 
executing a program. 

A call to a function or subroutine in 
the source code that is outside the 
calling program body. 

The number of failures divided by the 
central processing unit (CPU) time for 
the interval. (See error rate.) 

An unacceptable result produced during 
the operation of the computer pro- 
gram. Occurs when a fault is evoked 
by some input data. (See error.) 
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fault A specific manifestation of an error, 

A fault is evidenced when entry of 
some input data results in the program 
failing to correctly perform a re- 
quired function. 

file A collection of data treated as a unit. 


flight dynamics 
software 


flow chart 


form 


- change report 


Applications to support attitude deter- 
mination and control, maneuver plan- 
ning, orbit adjustment, and general 
mission analysis. 

A graphical representation of an al- 
gorithm in which symbols are used to 
represent operations, data, data flow, 
equipment, etc. 

Questionnaire used to record informa- 
tion about the software development 
process and/or software product. 

Records software changes and error 
data. 


- component status 

Records 

- component 

Records 

summary 

nents. 

- data base 

Used to 

problem report 

on data 

- maintenance 

Records 

change report 

data. 


time expended for activities, 
the status of system compo- 

identify and initiate action 
base problems. 

software changes and error 


- project summary Used to classify the project and meas- 
ure development progress. 


resource summary Records expended resources. 


- run analysis Used to monitor activities for which 

the computer is used. 

formal specification A specification technique based on a 

strict set of rules for describing the 
specification and usually involving 
the use of an unambiguously defined 
notation (for example, mathematical 
functions or formal program design 
language (PDL) ) . 

formal testing Testing performed in accordance with 

customer-approved test plans. Veri- 
fies that the software system is oper- 
ating according to the requirements of 
the development specifications. 


r 
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format statement 


function 


functional 

specification 


Halstead measures 


hardest first 


hardware 


hardware reliability 


hierarchy 


high-level language 


HIPO (hierarchical 
input process 
output) 


historical 


identifier 


A source language statement providing 
the necessary type and location infor- 
mation for read/write variables. 

A mathematical subprogram used to 
specify an input set, an output set, 
and the relationship between the two. 

A specification of a software component 
as a set of functions defining the 
output for any input. Emphasizes what 
a program is to do rather than how to 
do it . 

Measures developed by M. Halstead in 
his theory of "software science," 
based on basic elements of programming 
languages: operator, operand, length, 

volume, and language level. 

The development approach of designing 
(or implementing) the most difficult 
aspects of a system first. 

The physical and electronic components 
of a computer system including input/ 
output devices, CPU, memory, etc. 

A measure of the probability of a 
hardware system operating without 
failure, usually measured as MTTF 
(mean time to failure) . 

A ranked series of elements, such as 
tasks, programs, people, functions, 
etc . 

A programming language that does not 
reflect the structure of any one given 
computer or that of any given class of 
computers. 

A software design technique that de- 
fines each component in terms of a 
transformation from an input data set 
to an output data set, usually repre- 
sented in graphic form. 

Of or pertaining to data archives on 
past experience with particular proj- 
ects. 

A symbol whose purpose is to identify, 
indicate, name, or locate a data 
structure or procedure entry point. 
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impact 

implementation 

informal testing 
input/output (I/O) 

instruction 

integration 

integration test 

interactive 

interface 

interface testing 
interpret 


interrupt 

iteration 


The magnitude of effort or effect 
associated with a particular task or 
change in requirements, software, etc. 

Development phase involving code and 
unit testing. (See code and unit 
test. ) 

Testing involving no formal, written 
test plan. 

Usually refers to data or hardware 
processes involving the transfer of 
information to or from computer main 
memory. 

(See executable statement.) 

The combination of sybunits into an 
overall unit or system by means of 
interfacing. 

A test of several modules to check 
that the interfaces are implemented 
correctly. 

A mode of computer operation in which 
each line of input is immediately 
processed; allows communication with 
the program during its execution. 

The set of data and control informa- 
tion passed between two or more pro- 
grams or segments of programs and the 
assumptions made by each program about 
how the others operate. 

Validation that a module or set of 
modules operates within agreed inter- 
face specifications to ensure proper 
data and logical communications. 

To translate and execute one step 
(statement) at a time; to execute 
high-level language programs by trans- 
lating each statement to a correspond- 
ing sequence of machine operations 
before proceeding to the next state- 
ment. 

Any stopping of a process in such a 
way that it can be resumed. 

Repetition of a sequence of instruc- 
tions until a specified set of condi- 
tions is satisfied. 
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iterative 

enhancement 

IV&V 

job 

job control language 
(JCL) 

level of effort 
librarian 


life cycle 


lines of code (LOG) 
- adjusted 


delivered 


The design (or implementation) of suc- 
cessive versions, each producing a 
usable subset of the final product, 
until the entire system is fully 
developed. 

A software methodology employing inde- 
pendent verification and validation 
techniques. 

A unit of computer work consisting of 
one or more steps such as compilation, 
assembly, or utility runs. 

A program language controlling the use 
of computet system resources. 

Effort expended as needed and avail- 
able. 

Programming support personnel whose 
responsibilities include processing 
source statements but not writing them 
(for example, maintaining libraries, 
updating code, and producing tape 
backups) . 

Sequence of phases during which the 
software product is developed from 
concept through testing and comple- 
tion. (See individual phases: pre- 

task planning, requirements analysis, 
preliminary design, Retailed design, 
code and unit testing, system integra- 
tion and testing, acceptance testing, 
maintenance and operation. ) 

Eighty character card images of source 
code (programming language statements) 

An estimate of the number of execut- 
able lines of code. Includes all new 
code plus 20 percent of the reused 
code, minus 50 percent estimated as 
the amount of comment lines, minus 
10 percent estimated as the amount of 
nonexecutable statements. 

Total number of lines of source code 
generated as a deliverable item for a 
project. Includes executable, non- 
executable, and comment statements and 
all statements newly coded as well as 
statements taken from existing pro- 
grams and library routines. 
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- developed 

- executable 


- modified 

- new 


- old 


reused 


Total number of new lines of source 
code plus 20 percent of reused code. 

Code that changes the value or state 
of a program or data. 

Changed, existing code. 

Total number of lines of source code 
written by programmers for a given 
task. Does not include any code that 
was taken from previously existing 
programs, but does include comments, 
executable, and nonexecutable state- 
ments. 

Total number of lines of source code 
taken from previously existing pro- 
grams. Sometimes refers to reused 
unchanged. 

Same as old lines of code. 


load module 


machine language 


macro 


main program 


maintenance 


management, software 


An executable program produced by 
translating and linking source code. 

A system of numeric operation codes, 
values, and addresses, a sequence of 
which can be directly executed by a 
computer. 

A single instruction in a source lan- 
guage that represents a defined se- 
quence of source instructions in the 
same language. A macro is replaced by 
the sequence it represents before pro- 
gram translation. 

A program unit containing at least one 
executable statement and having a 
starting address for program execu- 
tion; normally, the set of instruc- 
tions that determines the basic 
sequence of control. 

The process of modifying existing 
operational software to correct errors 
or enhance capabilities while leaving 
its primary function intact. 

All the technical and management 
activities, decisions, and controls 
directly required to purchase, de- 
velop, or maintain software throughout 
the life cycle and maintenance phases. 
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management, 

technical 

manpower 

measure 


methodology 


metric 

microcomputer 


microprocessor 


mission date 


model 


modification 


Planning, organization, motivation 
(direction) , and control of a tech- 
nical project and technical personnel. 

The level or amount of total human 
effort required or used for a project. 

A count or numerical rating of the 
occurrence of some property. Examples 
include lines of code, number of com- 
puter runs, person-hours expended, and 
degree of use of top-down design 
methodology. 

A prescribed set of principles for the 
development process. These principles 
may pertain to requirements, design, 
code, testing, or management. Ex- 
amples include structured analysis, 
top-down design, information hiding, 
structured programming, formal test 
plans, and configuration management. 

(See measure. ) 

A class of computer having all major 
central processor functions contained 
on a single integrated circuit (MPU) . 
Typically implemented as the MPU plus 
a small number of supporting inte- 
grated circuits and characterized by a 
word size not exceeding 16 bits. 

A single integrated circuit (MPU) that 
performs the functions of a central 
processing unit (CPU) . 

The date that the system must be oper- 
ational, usually 2 months before 
launch. 

Equation relating two or more quanti- 
tative factors. A resource utiliza- 
tion model may provide an estimate of 
the cost of a project; a reliability 
model may indicate when sufficient 
testing has been done. 

The process of altering a program and 
its specification to perform either a 
new task or a different but similar 
task. 
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modified code 
module 

module test 
new lines of code 
object module 


online processing 

operand 

operator 

operating system 


operation 


optimization 


overlay 


parameter 

parse 


phase 


(See lines of code.) 

A named subprogram unit that is inde- 
pendently compilable. 

The test of a single module. 

(See lines of code.) 

A computer program expressed in 
machine language, usually the result 
of translating a source program by an 
assembler or compiler. 

Interactive processing, between humans 
and the computer. 

(See Halstead measures.) 

(See Halstead measures.) 

A system of routines and services that 
monitors, controls, allocates, deal- 
locates, and manages system resources 
and the execution of application 
programs and other system routines. 

A function that transforms data ob- 
jects from input domain (s) into data 
objects in the operation's output do- 
main (s) . 

A change in the source code to improve 
program performance, for example, to 
make it run faster or use less space. 
Optimization changes are not error 
corrections; however, if a change is 
made to use less space in order to 
conform to a specified space con- 
straint, the term "error" applies. 

A hierarchical structure of program 
components that allows the program to 
be executed while only part of it is 
in memory at any given time. 

A variable dr measure that can take on 
more than one value, but only one at a 
time . 

To decompose a sequence of symbols 
unit (block, line, phrase, word) into 
a set of elementary subunits (lines, 
words, commands, characters) . 

(See life cycle.) 
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precompiler 


preliminary design 
pretask planning 


preventive 

maintenance 

procedure 

procedural 

specification 

process design 
language 

productivity 


program 

program complexity 


program design 
language (PDL) 


program listing 


A computer program used to add 
special-purpose capabilities to a lan- 
guage system. A precompiler trans- 
lates special features implemented as 
macros into regular instruction se- 
quences in a programming language. 

(See design phase.) 

Planning efforts leading up to re- 
quirements analysis; development of 
software development plans and esti- 
mates. 

Maintenance specifically intended to 
prevent faults from occurring. 

A sequence of steps that accomplishes 
some task. 

A specification of a software component 
in an algorithmic manner# stating how 
the program is to work. 

(See program design language.) 


Generally accepted as the quantity of 
code produced (lines of code per man- 
month) or the rate of production of 
computer software measured in the 
quantity of code and documentation 
produced. 

A sequence of instructions that di- 
rects the computer to perform a task. 

A function of the number of execution 
paths in the program and the diffi- 
culty of determining the path for an 
arbitrary set of input data. (See 
complexity. ) 

A language# often called pseudocode, 
used in the design and coding phases 
of a project# that contains a fixed 
set of control statements and a formal 
or informal way of defining arid oper- 
ating on data structures. 

The sequence of instructions making up 
a computer program# usually in the 
form of a printout. 


2-16 


9024 



program validation 


programming language 
project 

proof technique 

prototype 

quality 

quality assurance 
read 

real-time 

reliability 

requirement 


All techniques used to ensure correct 
programs, including system, and sub- 
system, and system integration testing. 

A formal language composed of state- 
ments and instructions that has a 
formal syntax and lexical rules and 
that can be used in composing computer 
programs that require translation to 
be machine executable. 

A software development effort with set 
goals and defined objectives that uses 
the technical and managerial capabili- 
ties of personnel, has a life cycle 
with fixed endpoints, and produces a 
specified product. 

A method for formally demonstrating 
that a piece of software performs ac- 
cording to its specifications. Proof 
techniques usually use some form of 
mathematical notation to describe the 
result of executing a program. 

A system developed with the intention 
of serving as a pattern for a future 
development effort. 

The degree to which software conforms 
to certain desirable characteristics. 
These may include, but are not limited 
to, correctness, reliability, usabil- 
ity, validity, efficiency, flexibil- 
ity, and maintainability. 

A planned and systematic procedure for 
ensuring that the product conforms to 
established technical requirements and 
quality standards. 

The reading by peers of code and de- 
sign materials to look for errors, 
invent tests, and. so on. 

A program that receives input from a 
process or activity and reacts in time 
to affect that process or activity. 

The probability that software will 
function without failure. 

A system specification written by the 
user to define a system to a devel- 
oper. The developer uses this speci- 
fication in designing, implementing, 
and testing the system. 
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requirements 

analysis 


requirements 

testing 


resource 


resource estimation 
model 


reused code 
review 


routine 

scheduling 


segment 


An analysis of the contents of the 
functional specification and require- 
ments document from a software system 
viewpoint, to recast the requirements 
in terms suitable for software design. 
The completeness and feasibility of 
the requirements are assessed; missing 
or to-be-determined requirements are 
identified; all external interfaces 
are specified; and the initial deter- 
mination and allocation of resources 
are made. 

The execution of a software product 
under controlled conditions to demon- 
strate that all stated or implied re- 
quirements and performance criteria 
have been met. 

Any person, equipment, or facility 
that may be allocated to the accom- 
plishment of a task. 

A model that attempts to relate meas- 
ures of manpower and/or computer time 
to measures of the software problem, 
product, process, and environment. 

May range from simple, single variable 
equations to complex interactive soft- 
ware packages. 

(See lines of code.) 

A formal meeting of several individ- 
uals for the purpose of examining de- 
sign, requirements, code (management 
review) . 

A subprogram or module. 

The allocation of time, and resources 
necessary to complete a given task or 
project. 

A contiguous piece of code that is 
unnamed and, hence, cannot be referred 
to as a single entity in a program 
statement. Could be one or several 
lines of a routine, subroutine, part 
of a data area, or an arbitrary con- 
tiguous section of memory. 
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Software Engineering An organization sponsored by the 

Laboratory (SEL) National Aeronautics and Space 

Administration/Goddard Space Flight 
Center (NASA/GSFC) and created for the 
purpose of investigating the effec- 
tiveness of software engineering 
technologies when applied to the 
development of applications software. 
The SEL was created in 1977 and has 
three primary organizational members: 
NASA/GSFC (Systems Development and 
Analysis Branch ) , The University of 
Maryland (Computer Sciences Depart- 
ment) , and Computer Sciences Corpora- 
tion (Flight Systems Operation) . The 
goals of the SEL are to understand the 
software development process in the 
GSFC environment; to measure the ef- 
fect of various methodologies, tools, 
and models on this process; and to 
identify and then to apply successful 
development practices. 

shared items Data and programs accessible by sev- 

eral components, such as COMMON 
blocks, external files, and library 
subroutines. 


simulated constructs Statements used to simulate structured 

control structures when the language 
to be used does not contain these 
structures. 


software 


software class 


software develop- 
ment life cycle 

software engi- 
neering 


Computer program code and its associ- 
ated data, documentation, and opera- 
tional procedures. 

The type of software according to con- 
tent and purpose: scientific, data 

processing, or control. 

(See life cycle. ) 


The scientific approach to software de- 
velopment employing proven cost- 
effective methodologies, tools, and 
techniques. 


software reliability (See reliability.) 

software testing The process of exercising software in 

an attempt to detect errors that exist 
in the code. (See formal testing.) 
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source statements 


specification 


- imprecise 


- precise 


- very precise 


specification- 

driven 


All statements input to a compiler. 
Includes executable statements (as- 
signment, IF, and GO TO) ; nonexecut- 
able statements (DIMENSION, REAL, and 
END) ; and comments. 

A description of the input, output, 
and essential function (s) to be per- 
formed by a component of the syste^. 
Produced by the organization that is 
to develop the system; that is, it can 
be thought of as the contractor's in- 
terpretation of the requirements. 

The input, output, and function of the 
component are loosely defined. Much 
of what is required is assumed rather 
than specified. The specification 
relies heavily on programmer experi- 
ence and verbal communication to get 
an unambiguous interpretation and a 
full understanding of what is needed. 

The input, output, and function of the 
component are well’ defined. There are 
underlying assumptions not specified, 
but it is assumed that any programmer 
working on the project, with experi- 
ence on a similar project, will under- 
stand these assumptions. It is 
possible to arrive at an ambiguous 
interpretation or misunderstanding of 
the specifications if the reader does 
not have enough experience with the 
problem or does not obtain further 
verbal communication. 

A completely defined description of 
the input, output, and function of a 
component. The implementer of a very 
precise specification need make few, 
if any, assumptions. It is almost 
impossible to arrive at an ambiguous 
interpretation or misunderstanding of 
the specifications. 

Uses the specifications of the program 
to determine test data; for example, 
generating test data by examining the 
input/output requirements and specifi- 
cations) . 
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staff-units 


standard 


string processing 


structure-driven 


structured code 


structured design 


structured 

programming 

stub 


subprogram 


A concept used to estimate or measure 
human energy expended on a particular 
project. Based on the length of a 
working day, 6 or 8 hours productive 
time or calendar time (for example, 
staff-months, staff-hours) . 

Any. specification that refers to the 
method of development of the source 
program itself, and not to the problem 
to be implemented (for example, using 
structured code, at most 100-line sub- 
routines, or all names prefixed with 
subsystem name) . 

Includes components that perform oper- 
ations on lists of characters. Nor- 
mally assumed to include functions of 
compilers, hash code string hookup, 
and array comparisons. 

Uses the structure of the program to 
determine test data? (for example, 
generating data to ensure that each 
branch of a program is executed at 
least once) . 

Code that uses only the structured 
constructs: DO WHILE (iteration) , 

IP-THEN-ELSE (selection) , and BEGIN- 
END (sequence) . 

The use of a modular, hierarchical 
design consistent with structured cod- 
ing practices. A set of techniques 
for reducing the complexity of large 
new programs by dividing them into 
independent modules. 

Programming with a limited set of con- 
structs? programming with structured 
code. 

A "dummy" software element used in 
place of an expected functional ele- 
ment until the expected element be- 
comes available. 

A module, separately compilable but 
not independently executable? a col- 
lection of program elements that 
provides a function or relatively 
independent functions with respect to 
the whole program. 
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subroutine 
subsystem 
support software 
systems software 

system 

system description 

system integration 
system size 

system test 
table handler 

task 

TBD 

technical management 


A subprogram that does not return a 
value associated with its name when 
invoked. 

A collection of subprograms that pro- 
vides a major function and is indepen- 
dent of any other subsystem. 

All programs used in the development 
and maintenance of the delivered oper- 
ational programs. 

Any package designed to affect, 
modify, extend, or change the normal 
available processing procedure of the 
operating system. Could include such 
components as error tracing or ex- 
tended input/output such as DAIO. 

A set or arrangement of software or 
hardware related or connected to form 
a unity capable of achieving the goals 
specified in its design. 

A document illustrating system base- 
lines, data flows, and processing de- 
scriptions. 

The process of combining system com- 
ponents to produce the total system. 

The total number of machine words 
needed for all instructions generated 
on the project plus space for data, 
library routines, and other codes; the 
total size of the system without using 
any overlay structure. 

The process of trying to find discrep- 
ancies between the system and its 
original objectives. 

Components that are specifically de- 
signed to generate or interpret infor- 
mation stored in a table format, such 
as the Generalized Telemetry Processor. 

A set of defined objectives. Multiple 
tasks are initiated to complete a 
project. (See project.) 

To be determined. 

(See management.) 
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telemetry 


test 

test plan 

test plan document 
testing 

- functional 

- unit 
timesharing 

tool 

top-down development 

top-down testing 
tree chart 


Data transmitted at regular intervals 
from sensors. 

A procedure designed to verify some 
aspect of the performance of a soft- 
ware system. 

A description of test conditions that 
includes inputs, expected outputs, 
parameter values, etc. 

A management document that describes 
how and when specified test objectives 
will be met for the formal test plan. 

Part of the software development proc- 
ess in which a software system is sub- 
jected to specific conditions to show 
that it meets the intended design. 

The execution of independent tests 
designed to demonstrate a specific 
functional capability of a program or 
software system. 

Test of a set of program statements 
treated logically as a whole. 

A mode of operation that provides for 
the interleaving of two or more inde- 
pendent processes on one functional 
unit. 

A software aid used during the auto- 
mated development process to facili- 
tate the work of development team 
members. Examples are requirements 
language processors, precompilers, 
code auditors, and test generators. 

The design (or implementation) of the 
system, starting with a single compo- 
nent, one level at a time, by expand- 
ing each component reference as an 
algorithm possibly calling other new 
components. 

Testing of modules that were produced 
in top-down order. 

An acyclic connected graph, often rep- 
resenting a hierarchy in which the 
edges are directed to denote a subor- 
dinating relationship between the 
joined nodes. 
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uncertainty 

unit 

unit test 
user 

user-defined 
user's guide 
utility 

validation 


verification 


walk-through 


work-around 


The probability of error, or the 
probable magnitude of error. 

A set of computer program statements 
treated logically as a whole; usually 
a module or subroutine. (See compo- 
nent.) 

Independent test of a unit. (See im- 
plementation and module test.) 

The individual at the man/machine in- 
terface who is applying the software 
to the solution of a problem. 

An entity determined by the user as 
input during program execution. 

A document designed to assist the user 
in operating the software product. 

^ny component that is generated to 
satisfy some general support function 
required by other applications soft- 
ware. 

The process of determining whether 
executing the system in a user en- 
vironment causes any operational dif- 
ficulties. The process includes 
ensuring that specific program func- 
tions meet their requirements and 
specifications . 

The process of determining whether the 
results of executing the software 
product in a test environment agree 
with its specifications. 

A formal meeting for the review of 
source code and/or design by project 
members for the purpose of error 
detection, not correction; a technical 
rather than management review. 

The method used to counteract the ef- 
fects of an error in a program when 
the cause of the error and, conse- 
quently, the location of the state- 
ments containing the error is not 
known or is inaccessible (for example, 
a compiler error) . 
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work unit 


A quantity defined to enable an esti- 
mator to break down project require- 
ments, and subsequently cost, into 
quantifiable deliverable items. Some 
common work units include the number 
of requirements, programs, subsystems, 
modules, pages of documentation, lines 
of code, and experience of developers. 
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SECTION 3 - ACRONYMS 


ALC 

ATR 

BMDP 

CAREM 

CAT 

COCOMO 

CSC 

DARES 

DBA 

DBAM 

GESS 

GSFC 

HIPO 

IV&V 

MPP 

MTTF 

PAN VALET 

PDL 

PRICES 

SAP 

SEL 

SFORT 

SLIM 

STL 

TBD 

TSO 

UM 


Assembly Language Code 

Assistant Technical Representative 

Biomedical Programs, P Series 

Cost and Resource Estimating Models 

Configuration Analysis Tool 

Constructive Cost Model 

Computer Sciences Corporation 

Data Base Retrieval System 

Data Base Administrator 

Data Base Maintenance Software 

Graphic Executive Support System 

Goddard Space Flight Center 

Hierarchical Input Processing Output 

Independent Verification and Validation 

Modern Programming Practices 

Mean Time to Failure 

Computer Program Analysis and Security System 

Program/Process Design Language 

Programmed Review of Information for Costing 
and Evaluation Software Model 

FORTRAN Static Source Code Analyzer Program 

Software Engineering Laboratory 

Structured FORTRAN Preprocessor 

Software Life-Cycle Management Estimating Model 

Systems Technology Laboratory 

To Be Determined 

IBM Timesharing Option 

University of Maryland 
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